test: 핵심 도메인 서비스 단위 테스트 반영 + IDOR 3건 포함 버그 수정 (prod) - #220

createCourse/getCourseByUser/getPrivateCourseByUser/getCourseDetail/updateCourse/
deleteCourses 전체 메서드에 대해 정상 케이스 + 예외 케이스 + 경계값을 검증.

테스트 작성 중 실제 프로덕션 코드에서 3가지 의심되는 부분을 발견해 별도로 표시해둠:
- createCourse: 출발지 주소가 3토큰 미만이면 DepartureConverter가 null을 반환하고
  이후 NPE로 이어짐 (요청값 검증 부재)
- updateCourse: courseId로만 조회하고 userId로 소유자 검증을 하지 않아,
  다른 사람의 코스 제목도 수정 가능 (IDOR 의심)
- getCourseDetail: RunnectUser가 equals/hashCode를 오버라이드하지 않아 isNowUser 판정이
  참조 동일성에 의존함 (같은 id라도 인스턴스가 다르면 다른 사람으로 판정될 수 있음)

1. DepartureConverter: 출발지 주소가 3토큰 미만이면 null 대신
   BadRequestException(VALIDATION_DEPARTURE_ADDRESS_EXCEPTION)을 던지도록 변경
   (기존엔 CourseService에서 바로 NPE로 이어짐)
2. CourseService.updateCourse: findById → findByCourseIdAndUserId로 변경해
   본인 소유 코스만 수정 가능하도록 수정 (IDOR 방지, deleteCourses와 동일 패턴)
3. RunnectUser: equals/hashCode를 id 기준으로 구현. 기존엔 참조 동일성에 의존해
   같은 유저라도 인스턴스가 다르면(Course.isMatchedUser, RecordService,
   PublicCourseService 등에서) 다른 사람으로 오판정될 수 있었음

CourseServiceTest의 관련 3개 테스트를 수정된 동작에 맞게 갱신하고,
RunnectUserTest를 새로 추가해 equals/hashCode 자체를 검증.

createRecord/getRecordByUser/updateRecord/deleteRecords 전체 메서드에 대해
정상 케이스 + 예외 케이스 + 경계값 검증 (18개).

테스트 작성 중 CourseService.updateCourse와 동일한 패턴의 버그 발견해 수정:
- updateRecord: userId 파라미터를 받지만 소유권 검증을 하지 않아 다른 사람의
  기록 제목도 수정 가능했음 (IDOR). deleteRecords는 이미 소유권을 검증하고
  있어서(PermissionDeniedException), 동일 패턴으로 맞춰서 수정.
  ErrorStatus.PERMISSION_DENIED_RECORD_UPDATE_EXCEPTION 추가.

getRecordByUser의 건강 데이터 조회 실패 시 전체 요청은 실패하지 않고
healthData만 null로 우아하게 처리되는 방어 로직도 별도로 검증함.

getPublicCourseTotalPageCount/getMarathonPublicCourse/searchPublicCourse/
recommendPublicCourse/getPublicCourseByUser/getPublicCourseDetail/
createPublicCourse/deletePublicCourses/updatePublicCourse 전체 메서드에
대해 정상 케이스 + 예외 케이스 + 경계값 검증 (38개).

테스트 작성 중 발견해서 함께 수정한 버그 4건:
1. PublicCourse에 equals/hashCode 부재 — RunnectUser와 동일한 참조비교 문제.
   scrap 목록과 publicCourse 목록을 서로 다른 쿼리로 가져와 비교하는 곳이
   5곳(getMarathonPublicCourse, searchPublicCourse, recommendPublicCourse,
   getPublicCourseByUser, getPublicCourseDetail)이라 isScrap이 잘못 표시될
   수 있었음. id 기준 equals/hashCode 추가로 일괄 해결.
2. getPublicCourseDetail: 삭제된 코스 체크 조건이 반대(`== null`)였고,
   심지어 예외를 생성만 하고 throw를 안 해서 완전히 죽은 코드였음. 조건
   반전 + throw 추가.
3. updatePublicCourse: userId를 받으면서 소유권 검증을 안 해 다른 사람의
   공개 코스 제목/설명도 수정 가능했음 (IDOR). deletePublicCourses와
   동일한 관리자 예외 패턴으로 소유권 검증 추가.
   ErrorStatus.PERMISSION_DENIED_PUBLIC_COURSE_UPDATE_EXCEPTION 추가.
4. recommendPublicCourse: sort 파라미터가 "scrap"/"date" 둘 다 아니면
   Page 변수가 null로 남아 NPE. 이미 정의돼 있던
   INVALID_SORT_PARAMETER_EXCEPTION을 실제로 사용하도록 수정.

getMyPage/updateUserNickname/getUserProfile/deleteUser 전체 메서드에
대해 정상 케이스 + 예외 케이스 + 경계값 검증 (17개).

테스트 작성 중 발견해서 수정한 버그:
- updateUserNickname: 중복 닉네임 체크를 유저 조회보다 먼저, 그리고
  본인의 현재 닉네임과 비교 없이 수행하고 있어서, 본인의 기존 닉네임을
  그대로 다시 저장하려고 해도 "이미 존재하는 닉네임"으로 거부됐음.
  유저 조회를 먼저 하고, 요청 닉네임이 현재 닉네임과 다를 때만 중복
  체크를 하도록 순서/조건 수정.

createAndDeleteScrap/getScrapCourseByUser 전체 메서드에 대해
정상 케이스 + 예외 케이스 + 경계값 검증 (9개).

테스트 작성 중 발견해서 수정한 버그:
- createAndDeleteScrap: 스크랩한 적 없는 코스를 "취소"(scrapTF=false)
  요청하면 scrap 변수가 null이라 scrap.updateScrapTF(false) 호출 시
  바로 NPE(500)가 났음. 클라이언트가 중복 취소 요청을 보내거나
  race condition만 있어도 쉽게 재현 가능한 케이스라 조건 분기 추가로
  null이면 조용히 무시하도록 수정 (idempotent하게).

createHealthData/getHealthData/getHealthSummary/deleteHealthData 전체
메서드에 대해 정상 케이스 + 예외 케이스 + 경계값 검증 (22개).

버그는 발견되지 않음 — 소유권 검증(record.getRunnectUser().getId().equals(userId))을
일관되게 사용하고 있고, 동시성 경쟁으로 인한 유니크 제약 위반도
DataIntegrityViolationException을 잡아 409로 변환하는 등 이번에 테스트한
서비스 중 가장 방어적으로 잘 짜여있었음.

MDC userId 로깅 기능(dev의 f1a7044, 2914ae5)은 이 브랜치가 아직 갖추지
못한 로깅 기반 인프라(MdcLoggingFilter, logback-spring.xml 등, dev 전용
모니터링 인프라 구축 작업에 딸려있음)에 의존하고 있어 이번엔 함께
가져오지 않았다. UserIdResolver 자체의 토큰 검증/파싱 로직은 동일하게
유효하므로 테스트는 유지하되, MDC 관련 assertion만 제거.